The article by Van Jacobson et al. entitled “Networking named content” and published in 2009 in the Proceedings of the CoNEXT'09 Conference, describes a novel architecture centered on contents, known as “content-centric networking”. That architecture proposes changing the present communications model that is based on physical addressing in the network by a new communications model that is based on addressing by content names.
A stream may be delivered for various applications, optionally in real time, and it is identified in the communications network by a stream name or identifier. The stream is made up of data segments. A data segment is identified by the stream identifier together with a segment number.
More precisely, in order to obtain a data segment of a stream, a client entity sends a request relating to the data segment, which request is referred to as an “interest packet”. On receiving the request, a routing node verifies whether it has the looked-for data segment. If so, it then sends it to the interface via which the request was received, so that it can be received by the client entity, possibly passing via other routing nodes, where applicable. If the routing node does not have the looked-for data segment, it checks a pending interest table (PIT) of pending requests to verify whether it has already transmitted a request relating to the same data segment. If not, it stores the identifier of the looked-for data segment in the PIT in association with an identifier of the interface from which the request relating to the looked-for data segment was received. Thereafter it routes the request through the communications network as a function of the stream identifier. Otherwise, i.e. when the PIT already includes the identifier of the looked-for data segment, it does not transmit the request it has received, but acts in the PIT to associate the identifier of the looked-for data segment with an identifier of the interface via which the request was received. In this communications model, it can be seen that each routing node serves to aggregate requests relating to a given data segment of a stream. At various steps in the processing of the data segment, the routing device might put the data segments into a queue prior to routing them. In the event of congestion in one of the queues of the routing node, a new received data segment is generally not stored and consequently is not routed. The effect of not routing this data segment, given the aggregation function of the routing node, is to fail to satisfy a plurality of client entities that have requested the data segment. The number of client entities involved depends on the amount of aggregation that has been performed during the processing of the request relating to a data segment of the stream. It should be recalled that in the conventional communications model, in a packet-switched communications network with physical addressing, only one client entity is impacted by the deletion of a packet that it has requested.